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Abstract 


This document specifies an extension to the multicast addressing 
architecture of the IPv6 protocol. The extension allows the use of 
Interface Identifiers (IIDs) to allocate multicast addresses. When a 
link-local unicast address is configured at each interface of a node, 
an IID is uniquely determined. After that, each node can generate 
its unique multicast addresses automatically without conflicts. The 
alternative method for creating link-local multicast addresses 
proposed in this document is better than known methods like unicast- 
prefix-based IPv6 multicast addresses. This memo updates RFC 3306. 
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Introduction 


This document defines an extension to the multicast portion of the 
IPv6 addressing architecture [RFC4291]. The current architecture 
does not contain any built-in support for dynamic address allocation. 
The extension allows for use of IIDs to allocate multicast addresses. 
When a link-local unicast address is configured at each interface of 
a node, an IID is uniquely determined. After that, each node can 
generate its unique multicast addresses automatically without 
conflicts. That is, these addresses could safely be configured at 
any time after Duplicate Address Detection (DAD) has completed. 


This method for the link-local scope is preferred over unicast- 
prefix-based IPv6 multicast addresses [RFC3306], since by delegating 
multicast addresses using the IID, each node can generate its 
multicast addresses automatically without allocation servers. This 
method works better than the unicast-—prefix—based method with 
applications in serverless environments such as ad-hoc and network 
mobility. This document restricts the usage of defined fields such 
as the scop, plen, and network prefix fields of [RFC3306]. 

Therefore, this document specifies encoded information for link-local 
scope in multicast addresses. 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


Applicability 


The allocation technique in this document is designed to be used in 
any environment in which link-local scope IPv6 multicast addresses 
are assigned or selected. This method goes especially well with 
nodes supplying multicast services in a zeroconf/serverless 
environment. For example, multicast addresses less than or equal to 
link-local scope are themselves generated by nodes supplying 
multicast services without conflicts. Also, hosts that are supplied 
multicast services from multicast servers then make multicast 
addresses of multicast servers using ND (address resolution) and 
well-known group IDs [RFC2461]. 


Consequently, this technique MUST only be used for link scoped 
multicast addresses. If you want to use multicast addresses greater 
than link-local scope, you need to use other methods as described in 
[RFC3306]. 
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Link-Scoped Multicast Address Format 


This document specifies a new format that incorporates IID in the 
link-local scope multicast addresses. 


Figure 1 illustrates the new format for link-scoped multicast 
addresses. 


Figure 1. Link-Scoped Multicast IPv6 Address Format 


The flgs, scop, and plen fields are used to identify whether an 
address is a multicast address, as follows: 


1. flgs MUST be "0011". 

2. scop MUST be <= 2. 

3. The reserved field MUST be zero. 

4. The "plen" field is a special value, "1111 1111" (decimal 255). 


The IID field (replacing the 64-bit prefix field from [RFC3306]) is 
used to distinguish each node from others. Given the use of this 
method for link-local scope, the IID embedded in the multicast 
address MUST only come from the IID of the link-local unicast address 
on the interface after DAD has completed. That is, the creation of 
the multicast address MUST only occur after DAD has completed as part 
of the auto-configuration process. 


Group ID is generated to indicate a multicast application and is used 
to guarantee its uniqueness only in the host. It may also be set on 
the basis of the guidelines outlined in [RFC3307]. 


Example 
In an Ethernet environment, if the link-local unicast address is 


FE80::A12:34FF:FE56:7890, the link-scoped multicast prefix of the 
node is FF32:00FF:A12:34FF:FE56:7890::/96. 
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Consideration of Lifetime 


Generally, link-scoped multicast addresses have no lifetime, because 
link-local unicast addresses also have no lifetime. However, this is 
not true in the mobile environment. Even though multicast addresses 
are created from the unique IIDs of unicast addresses, their useful 
lifetime is linked to the period during which the IID is known to be 
unique. Thus, conflict is possible between IIDs, due to a new node 
in merged network that uses the same IID as a powered node. 


In this scenario, DAD also fails to guarantee uniqueness of the 
unicast address, but this document does not try to address this 
issue. 


Security Considerations 


The uniqueness of multicast addresses using this method is guaranteed 
by the DAD process. So, a secure DAD process is needed for stability 
of this method. This document proposes the mechanism in [RFC3041] 
for this purpose. 


[RFC3041] describes the privacy extension to IPv6 stateless address 
autoconfiguration to configure the IID of non-link-local scope 
unicast addresses. [RFC3041] cannot be used for making a link-local 
unicast address, and hence it cannot be used to create an IID for 
link-scoped multicast address. However, as [RFC3041] does not 
protect the privacy of link-local unicast addresses, it does not seem 
to be required to protect the privacy of IID-based link-local 
multicast addresses. 
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